sequenceDiagram
    participant V as W3DView
    participant F as ScreenDefaultFilter
    participant S as W3DSmudgeManager
    participant D as D3D8 Device

    Note over V,D: OLD PATH - RTT broken under forced MSAA
    V->>F: filterPreRender
    F->>D: startRenderToTexture - SetRenderTarget with MSAA depth
    Note over D: Silent depth corruption, black screen
    V->>D: doRender into RTT texture
    V->>F: filterPostRender - endRenderToTexture, blit fullscreen
    V->>S: render smudges over blit

    Note over V,D: NEW PATH - CopyRects always safe
    V->>F: filterPreRender
    F-->>V: return FALSE, RTT never started
    V->>D: doRender directly to back buffer
    Note over V,F: filterPostRender is NOT called
    V->>S: render
    S->>S: testHardwareSupport - SMUDGE_SUPPORT_YES via m_backgroundTexture
    S->>D: Get back buffer surface
    S->>S: background Copy from back buffer
    S->>D: draw smudge quads using copied background texture

This is a comment left during a code review.
Path: Core/GameEngineDevice/Source/W3DDevice/GameClient/W3DShaderManager.cpp
Line: 183-187

Comment:
**`postRender` is now permanently dead code**

`ScreenDefaultFilter::preRender` always returns `FALSE`, so `W3DView.cpp` gates `filterPostRender` behind `if (preRenderResult)` and this function is never invoked. Despite that, it still calls `W3DShaderManager::endRenderToTexture()` and asserts on the result. Since it can never be reached through the normal filter dispatch, the assertion will never fire — but the function body is now misleading for future maintainers, and it references the RTT texture that is no longer populated for this filter. Consider either removing the body (returning `false` immediately with a comment) or removing the function entirely if no derived class relies on it.

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: f7ffb6a}

Maybe we can accurately tell if MSAA was forced with some of the changes in #1073 like below, and use that in place of desc.MultiSampleType

static D3DFORMAT _Get_D3D_Back_Buffer_Format() { return DisplayFormat; }
...
WWINLINE unsigned int DX8Wrapper::Bytes_Per_Pixel(D3DFORMAT format)
{
	switch (format)
	{
	// 8-bit formats
	..
	// Depth / stencil
	case D3DFMT_D16_LOCKABLE:
	case D3DFMT_D16:
	case D3DFMT_D15S1:
	case D3DFMT_D24S8:
	case D3DFMT_D24X8:
	case D3DFMT_D24X4S4:
	case D3DFMT_D32:
		return 0;
		...
}

Do you know if the RTT path is much faster when MSAA is off compared to copyRects? Is it worth the extra complexity to support both?

Maybe we can accurately tell if MSAA was forced with some of the changes in #1073 like below, and use that in place of desc.MultiSampleType

To find this bug I tested a benchmark, but the test ran differently on different vendors, is this needed?
https://github.com/githubawn/GeneralsGameCode/tree/fix/nvidia-microwave-aa-clean/benchmark

Do you know if the RTT path is much faster when MSAA is off compared to copyRects? Is it worth the extra complexity to support both?

I tried benchmarking them, but the game lacks robust benchmarking tools. Using CapFrameX with a DX8 bridge means we’re mostly benchmarking the wrapper’s translation overhead; there’s too much fluctuation between runs to see a real difference between RTT and copyRects. It might be worth keeping both around in case we move to a native DX9 base where RTT isn't broken?

I tried benchmarking them, but the game lacks robust benchmarking tools. Using CapFrameX with a DX8 bridge means we’re mostly benchmarking the wrapper’s translation overhead; there’s too much fluctuation between runs to see a real difference between RTT and copyRects. It might be worth keeping both around in case we move to a native DX9 base where RTT isn't broken?

If you're up for it you could give #2202 a try; add a zone in the smudge code, then do a testrun on a replay or something that's kinda reproduceable. Tracy can compare histograms of zones between two different captures

I actually tried to set this up by bringing the Tracy profiling (#2202) into this branch to compare them.

Looking at the traces, the overall render zone copy is almost invisible below PassDefault in both pathways. The smudge rendering is incredibly fast either way. I added the detail zones and did a direct comparison between the RTT and CopyRects (smudge copy) pathways.

A true 1:1 benchmark would require reverting to a pre-safety commit, reapplying Tracy, and resolving build conflicts, which I've partially done but found overly time intensive.

Given the minimal frame time impact, I think CopyRects is sufficient here, but if you have ideas for a cleaner benchmark setup, I'm happy to iterate.

These are the results:

Very cool! Seems that CopyRects is the way to go.

You can inspect the histogram of a zone by going to Statistics and then clicking on your zone which gives an image like this:

By pressing Ctrl + Numpad+ you can increase the max render FPS so that would maybe make the differences easier to see (if any)

To find this bug I tested a benchmark, but the test ran differently on different vendors, is this needed? https://github.com/githubawn/GeneralsGameCode/tree/fix/nvidia-microwave-aa-clean/benchmark

I will take a look at this soon

Edit: D3DFormat doesn't appear to report accurately either, so it's not useful for detecting forced MSAA. Maybe you can use the surface mismatch that's throwing API errors as detector, (if it's important to detect this... maybe not)

Title needs updating because it is not Nvidia specific bug.

⚠️ Title/Commit Validation Failed

Invalid commit messages:

• Update Core/Libraries/Source/WWVegas/WWLib/WWCommon.h
• implemented greptile feedback
• implemented last feedback
• implemented some feedback
• Update Core/GameEngineDevice/Source/W3DDevice/GameClient/W3DSmudge.cpp
• Fix Microwave blackout on (Nvidia) forced AA
  PR titles and commit messages must follow conventional commits format:

type: Description
type(scope): Description

Allowed types: bugfix, build, chore, ci, docs, fix, feat, perf, refactor, revert, style, test, tweak, unify

See CONTRIBUTING.md for details.

So this could do with a followup to remove all of the RTT code from the smudge filter